Subject: CP-CP session failure after link failure

From: "Ralph Case" <[email-masked]>
Date: Thu, 11 Jul 96 13:23:51 EDT

I agree that this sounds like a problem.

The suggestion that comes to mind immediately is to use the
HPR Control Flows Over RTP Tower.  When the link failure is
discovered, the path can be switched to TG2 without disrupting
the CP-CP sessions.

I can understand that some may not like this solution, but it
does fit well with the current architecture and does not have
dangerous side effects.

Alternatively, when NN2 gets to its "session limit exceeded"
code, it might "ping" NN1 over the existing CP-CP sessions.
This should cause the link failure to be detected and a
subsequent retry should work.  This is a change to the current
architecture, and would hit all existing NNs, but it seems to
me it would migrate.  Clearly some details need to be worked out.

Are there any more suggestions?

I'll add this item to the SIG agenda for next week.

I'm not sure I understand the part about Locates failing:

> There is also the added problem that during the life of NN2's
> link-inactivity timer the CP-CP sessions between NN1 and NN2 appear to be
> active and directed LOCATEs routed across them will fail (causing
> increased broadcast LOCATE traffic in the network and causing some
> session activation flows to fail).

When NN1 notices the link is down, it reports that via a TDU
and once the topology is propagated, there will be no more
Locates flowing from NN1 to NN2.  The first time there is a
Locate flowing from NN2 to NN1 it should cause NN2 to notice
that the link is down also.  There may be a few misdirected
locates in the transient network, but they should stop
quickly.

Ralph Case                    [email-masked]    (919)254-1882
APPN/APPC Architecture & Application Enablement
IBM Networking